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ABSTRACT 


A  large  literature  is  there  on  congestion  control  and  that  is  based  on  optimization  and  control  theories  in  some 
recent  year.  First  TCP  friendly  congestion  control  has  been  discussed,  the  classification  criteria  of  TCP  friendly  congestion 
control  has  been  analyzed  like  Network  supported,  end  to  end,  unicast,  multicast,  single  rate  and  multi  rate.  This  paper 
provides  an  overview  of  optimization  flow  control,  traces  the  development  in  a  framework,  from  uni  cast  to  multicast. 
A  demand  is  growing  for  efficient  multimedia  streaming  applications  over  the  Internet.  These  new  transport  protocols 
could  cause  congestion  collapse  if  they  are  widely  used  but  do  not  provide  adequate  congestion  control.  The  system  models 
for  multicast  congestion  control  are  evaluated,  and  then  identify  three  key  problems:  feedback  implosion,  congestion 
indicator  filtering  and  fairness. 
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Network  congestion  occurs  when  a  link  or  node  is  carrying  so  much  data  that  its  quality  of  service  deteriorates. 
Networks  using  these  protocols  can  exhibit  two  stable  states  under  the  same  level  of  load.  The  stable  state  with  low 
throughput  is  also  known  as  congestive  collapse.  Multicast  system  also  improves  the  efficiency  of  the  data  that  has 
multipoint  distribution.  It  builds  a  distribution  tree  from  a  sender  to  a  set  of  receivers.  By  the  increasing  popularity  of  group 
communication  appUcations  has  led  to  a  great  deal  of  interest  in  the  development  of  multicast  transport  protocols  layered 
on  top  of  IP  multicast.  However,  these  new  transport  protocols  could  cause  congestion  collapse  if  they  are  widely  used  but 
do  not  provide  adequate  congestion  control.  The  success  of  the  Internet  relies  on  the  fact  that  TCP  sessions  respond  to 
congestion  by  reducing  their  load  presented  to  the  network  [1]  [2]. 

TCP  provides  the  reliable  data  transfer  and  also  supports  flow  and  congestion  control.  There  are  various  schemes 
for  congestion  control  for  TCP.  Some  non  TCP  application  are  also  present  on  internet  which  do  not  have  congestion 
control  mechanism  and  these  application  do  not  share  bandwidth  fairly  with  TCP  based  application. 

Some  unfairness  has  occurred  because  as  the  traffic  from  such  TCP  unfriendly  application  like  IP  telephony, 
video  conferencing,  audio  conversations,  online  movies  is  increasing  so  there  exists  a  need  to  solve  this  unfairness.  TCP 
flow  adjust  their  flow  rate  if  somewhere  congestion  is  detected  but  non  TCP  flow  continue  to  send  at  same  uncontrolled 
rate.  Because  since  these  have  strict  latency  requirements  than  reliable  delivery  causing  unfairness,  and  in  worse  case 
leading  to  congestion  collapse  [1]. 

Case  of  multicast  is  even  worse  as  in  this  case  different  members  of  group  may  have  different  characteristics  and 
also  congestion  level  of  receiver  link  can  also  be  different.  If  a  sender  adjusts  its  sending  rate  for  every  loss  indication  by 
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receiver  then  its  transmission  rate  will  be  completely  throttled  so  there  is  a  need  to  find  a  way  to  select  most  suitable 
receiver  such  that  most  congested  path  is  selected  and  network  bandwidth  is  utilized  to  maximum  possible.  In  this  paper 
we  discuss  different  proposed  TCP  friendly  congestion  control  schemes  [1][4]. 

II.  CLASSIFICATION  CRITERIA 

TCP  friendly  congestion  control  schemes  can  be  classified  based  of  the  following  criteria. 

A.  End  to  End  and  Network  Supported 

The  classification  in  TCP  friendly  schemes  can  be  done  on  basis  of  where  the  congestion  control  mechanism  is 
implemented.  As  the  name  specifies  from  End  to  End  handles  the  congestion  control  without  relying  on  the  network 
components  just  like  routers  here  the  sender  adjust  the  data  flow  rate  based  on  the  feedback  provided  by  the  receiver. 

Receiver  decides  what  layers  to  join  in  layered  approach  for  multi  cast  traffic  as  we  will  see  later  receiver  can 
decide  whether  to  join  or  leave  layers  depending  upon  its  congestion  status.  It  will  also  support  congestion  control  by 
sending  its  feedback.  End  to  End  schemes  are  easy  to  implement  compared  to  network  supported  schemes  [1]  [4]. 

Routers  can  detect  congestion  and  send  feedback  to  sender  and  sender  can  adjust  its  sending  rate.  Compared  to 
end  to  end  where  sender  keep  pumping  data  at  same  rate  till  receiver's  feedback  is  received  network  assisted  congestion 
control  can  send  indicator  packets  to  its  parent  thus  control  starts  before  actual  steps  taken  by  senders. 

B.  Unicast  and  Multicast 

Unicast  sender  sends  data  to  only  one  receiver  at  a  time  thus  congestion  control  for  that  connection  solely  depends 
upon  network  condition  between  sender  and  receiver.  Non  TCP  flows  support  both  unicast  as  well  as  multicast  transfer. 
Compared  to  unicast  multicast  congestion  control  is  hard  to  design  since  in  this  case  sender  has  to  decide  how  to  adjust 
sending  rate  if  multiple  receiver  are  affected  by  congestion  and  sends  their  congestion  indicators,  if  sender  adjust  its 
sending  rate  for  every  CI  it  receives  then  the  transmission  rate  will  be  completely  throttled,  hence  there  is  a  need  to  select 
some  representative  or  a  way  to  filter  out  these  indicator  to  select  best  among  them  [6]  [7]  [8]. 

This  problem  is  further  affected  by  the  fact  different  receivers  may  have  different  bandwidth  thus  require  different 
flow  rates  to  fully  utilize  their  available  bandwidth  so  selecting  the  best  possible  congestion  representative  such  that 
congestion  problem  is  controlled  and  network  resource  are  utilized  to  best  possible  is  a  prime  need. 

C.  Single  Rate  Vs  Multi-rate 

At  the  point  of  definition,  in  single  rate  a  sender  send  data  at  same  rate  to  aU  the  receivers.  This  approach  limits 
the  maximum  transfer  rate  for  all  the  receivers  since  all  receivers  will  get  data  at  same  rate  that  is  limited  by  the  rate  of 
bottleneck  receiver,  whereas  in  multi-rate  a  sender  sends  data  at  multiple  rates. 

In  Multi-rate  schemes  the  source  maintains  several  layers  each  having  different  transmission  rates,  receivers 
depending  upon  their  network  bandwidth  and  congestion  status  can  subscribe  to  different  subset  of  layers.  Care  has  to  be 
taken  while  leaving  or  joining  a  multicast  group  for  most  effective  congestion  control  [1][7]. 

III.  SYSTEM  MODEL 

There  are  two  types  of  control  systems:  feedback  and  open-loop  according  control  theory.  In  a  feedback  control 
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system,  the  result  of  the  control  is  measured  and  the  control  parameter  is  adjusted  on  the  fly.  In  an  open-loop  control 
system,  a  pre-determined  control  strategy  is  fixed  without  adjustment  on  the  fly  [8]  [9]. 

However,  the  current  Internet  provides  best  effort  service.  Quality  of  service  reservation  using  RSVP  has  not  been 
widely  deployed.  Without  service  reservation,  open-loop  congestion  control  is  difficult  to  implement. 

Figure  1  shows  our  model  of  the  feedback  congestion  control  system. 


Figure  1:  Congestion  Control  System  Model 

A  sender  congestion  control  component  accepts  data  from  its  upper  layer.  It  then  uses  the  control  parameter  c  to 
decide  if  it  can  put  more  data  into  the  network.  If  so,  it  sends  data  to  the  receivers  using  IP  multicast.  It  use  a  thin  solid  line 
to  represent  each  data  path.  Receivers  will  send  feedbacks  to  the  sender.  The  control  parameter  c  should  be  adjusted 
according  to  network  traffic  conditions.  We  call  the  algorithm  to  estimate  c  the  estimation  algorithm  [10][1 1][12]. 


dllMHI 


Co  ml 


J. 


Figure  2:  Fstimation  Algorithm  System  Model 

•  Control  Parameter 

The  control  parameter  can  be  either  window  or  rate.  If  it  is  a  window,  the  sender  can  send  any  new  data  into  the 
network  whenever  there  exists  space  in  the  window.  Otherwise,  if  the  parameter  is  rate,  the  sender  can  inject  new  data  no 
higher  than  the  rate.  The  advantage  of  window  control  is  that  it  integrates  naturally  with  error  control  and  flow  control. 
Also,  window  control  reacts  to  network  changes  faster  [13][I4]. 

The  advantage  of  rate  control  is  that  it  is  a  natural  control  parameter  for  certain  applications,  e.g.  streaming  media, 
which  have  intrinsic  sending  rates. 

•  Placement  of  Estimation  Algorithm 

The  sender  may  not  be  the  entity  that  runs  the  estimation  algorithm.  For  scalability  reasons,  it  can  be  more 
efficient  for  each  receiver  to  run  a  local  estimation  algorithm,  and  send  its  estimation  to  the  sender. 
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•  Congestion  Indicator  (CI) 

Selecting  the  right  CI  is  always  a  difficult  problem.  The  criteria  for  the  selection  of  CI  are: 

•  Is  it  a  good  indication  of  congestion? 

•  Is  it  easy  to  monitor? 

Below  4  types  of  congestion  indicators  are  discussed  and  many  other  types  can  also  be  designed.  NACK/  ACK. 
The  simplest  CI  is  receiving  (ACK)  or  missing  (NACK)  a  packet.  They  are  the  easiest  to  monitor,  and  give  the  fastest 
response.  Experience  of  TCP  shows,  that  they  work  fine  for  unicast  congestion  control.  However,  ACK/NACK  reflects 
only  instantaneous  network  congestion  status.  Drop-tail  router  and  traffic  phase  effects  generate  bursty  packet  loss. 
This  type  of  congestion  indicator  estimates  the  number  of  packets  queued  in  the  network  by  estimating  the  change  in  round 
trip  time  (RTT).  The  advantage  of  this  congestion  indicator  is  that  it  can  detect  congestion  before  packet  loss. 

Loss  Rate:  One  way  to  smooth  the  bursty  NACK/ ACK  congestion  indicator  is  to  use  loss  rate.  The  difficulty  is 
how  to  calculate  the  loss  rate.  If  the  calculation  period  is  too  short,  it  will  still  be  bursty.  If  the  calculation  is  over  a  longer 
period,  the  control  will  be  less  responsive  [13]. 

Incoming  Rate:  Another  way  to  smooth  the  bursty  NACK/ACK  is  to  measure  the  packet  incoming  rate. 
Congestion  can  be  detected  when  the  sender's  sending  rate  is  higher  than  the  receiver's  measured  incoming  rate. 
The  difference  between  these  two  rates  reflects  the  packet  loss  rate.  However,  calculating  the  incoming  rate  for  bursty 
traffic  is  not  straightforward. 

4.  Estimation  Algorithm:  The  control  parameter  c  will  be  continously  updated  according  to  the  received 
congestion  indicator.  In  this  paper,  we  define  two  specific  types  of  estimation  algorithms.  Other  types  of  estimation 
algorithms  can  be  designed  and  should  be  explored. 

IV.  KEY  PROBLEMS  AND  SOLUTION  APPROACHES 

With  the  above  control  model  and  terminology  in  mind,  we  next  discuss  the  key  problems  and  solution 
approaches. 

A.  Feedback  Implosion  Problem 

The  first  problem  facing  multicast  congestion  control  is  the  feedback  implosion  problem. 

For  a  sender  to  adjust  its  control  parameter  according  to  network  traffic,  it  must  receive  feedback  from  the 
receivers  (we  assume  no  exphcit  network  congestion  support)  [9][10][15].  Therefore,  we  have  to  deal  with  the  same 
feedback  implosion  problem  as  multicast  error  control.  We  identify  two  approaches  to  solve  the  feedback  implosion 
problem: 

•  Suppression-based 

•  Structure-based. 

Suppression:  In  this  approach,  not  all  receivers  will  send  their  feedbacks  to  the  sender.  One  solution  is  to  choose 
some  receivers  as  representatives,  and  only  the  representatives  send  their  feedbacks.  The  difficulty  with  this  approach  is 
how  to  select  a  suitable  set  of  representatives.  Another  suppression  approach  is  to  adapt  the  SRM  suppression  algorithm 
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designed  originally  for  reliable  multicast  error  control.  In  this  algorithm,  receivers  control  their  feedbacks  using  random 
timers.  This  adds  the  requirement  that  every  receiver  has  to  measure  the  distance. 

Structure-Based:  Another  approach  to  solve  the  feedback  implosion  problem  is  to  organize  the  receivers  into  a 
structure,  and  feedbacks  are  propagated  and  aggregated  through  the  structure.  MTCP  [8],  TFMCC  [12],  and  Golestani 
[10][1 1]  all  proposed  to  use  a  tree  hierarchy  to  aggregate  feedback  traffic. 

B.  Congestion  Indicator  Filtering  Problem 

The  second  problem  is  the  congestion  indicator  filtering  problem.  Unlike  TCP,  which  just  needs  to  control  the 
single  connection  between  a  sender  and  a  receiver,  multicast  congestion  control  has  to  support  a  wide  range  of  operating 
parameters  for  each  connection.  As  the  number  of  receivers  increases,  the  range  of  suitable  transmission  rates  diminishes. 
Several  approaches  have  been  proposed  to  filter  the  congestion  indicator: 

Representative:  This  approach  is  to  solve  the  feedback  implosion  problem,  will  also  reduce  the  impact  of  this 
problem.  Because  it  has  its  congestion  indicators  that  are  restricted  to  be  from  only  a  small  set  of  representatives,  it  reduces 
the  impact  of  this  problem.  Further  research  includes,  how  to  select  the  right  size  and  right  set  of  receivers  as 
representatives  needs  further  research. 

Suppression  Timer:  In  LTRC  (Loss  Tolerant  Rate  Controller),  the  sender  will  respond  to  only  one  loss  report  in 
a  time  period  TD.  The  time  TD  is  a  measure  of  the  time  it  takes  for  a  rate  change  to  "flush"  through  the  system.  The  paper 
gives  a  method  to  determine  TD.  The  difficulty  of  this  approach  is  to  make  the  tradeoff  between  responsiveness  and  the 
reduce-to  zero  problem.  The  effectiveness  of  this  approach  still  needs  further  study. 

C.  Fairness  Problem 

Multicast  congestion  control  has  one  more  difficulty  that  is  the  fairness  problem.  In  the  last  couple  of  years,  one 
key  challenge  in  multicast  congestion  control  is  the  lack  of  a  definition  for  fairness. 

In  the  first  section,  several  types  of  fairness:  max-min  fairness,  and  global  resource  fairness  has  been  discussed 
[9].  Over  the  last  years  TCP  has  become  the  standard  transport  protocol  as  well  as  the  widely  used  protocol  (90-95%  of  the 
bytes  or  packets)  in  the  Internet.  For  this  reason,  it  has  been  strongly  argued  that  multicast  congestion  control  should  be 
TCP-friendly.  One  seemingly  obvious  way  to  achieve  this  objective  is  to  use  the  TCP  congestion  indicator  (NACK/ACK) 
and  estimation  algorithm  (AIMD  algorithm)  to  do  multicast  congestion  control.  We  have  shown  this  will  lead  to  very  low 
throughput.  So  far,  two  approaches  show  promise  to  solve  both  of  the  congestion  indicator  filtering  problem  and  the 
fairness  problem. 

Golestani's  Approach;  In  this  approach,  the  congestion  indicator  is  still  the  NACK/ACK.  However,  to  avoid  the 
congestion  indicator  filtering  problem,  it  is  not  the  sender  but  each  receiver  that  runs  its  own  copy  of  estimation  algorithm 
[15].  Therefore,  it  solves  the  congestion  indicator  filtering  problem.  The  problem  with  this  approach  is  that  no  specific 
estimation  algorithm  has  been  described.  Also  there  is  still  no  experimental  validation  yet. 

TCP-formula  Approach:  The  main  and  basic  idea  about  this  approach  is  very  similar  to  golestani's  approach. 
The  individual  receiver  always  implements  the  estimation  algorithm.  However,  in  this  case,  the  rate  was  proposed  instead 
of  window  control.  With  the  help  of  these  feedbacks  from  receivers,  the  sender  will  select  the  minimum  of  the  rates  and 
adjust  its  sending  rate.  The  main  disadvantage  behind  this  approach  is  that,  each  of  the  receiver  will  measure  both  the 
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control  parameters  like  loss  rate  and  round  trip  time.  As  we  previously  discussed,  in  these  measurements,  a  tradeoff 
between  responsiveness  and  accuracy  must  be  made  in  these  measurements  [10][14]. 

V.  CONCLUSIONS 

In  this  paper  TCP  friendly  congestion  control  mechanism  has  been  widely  analyzed  and  discussed.  This  paper 
discusses  the  wide  range  of  problems  and  evaluation  mechanisms  in  the  field  of  congestion  in  mobile  network.  Making 
TCP  friendUness  is  because,  the  internet  non-TCP  flows  competes  with  TCP  one.  This  paper  also  Covered  schemes  for 
unicast  and  multicast  traffic,  also  a  survey  for  the  different  types  of  congestion  control  mechanism  applying  congestion 
based  on  different  traffic  need  single  rate  for  uniform  sending  rate  and  multi  rate  schemes  for  multiple  sending  rates. 
Various  schemes  have  been  proposed  in  these  recent  years  and  more  work  is  still  in  progress.  In  this  paper,  identified  3  key 
problems  and  discussed  the  current  prototyped  solutions. 
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